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(54) Dynamic ciasses of service for an international ctyptography framework 

(57) An international ayptography fiamework (ICF) , (14) has been replaced or tanpered with, 
allows manufacturers to comply with varying national 

laws governing the distrixition of cryptographic capai3il- : 

ities. The invention is concerned primarily with the appli- 
cation certificatkwi aspects of the frameworii where an 
application (29) that requeste cryptographic services 
from the ICF service elements is identified through 
some form of certificate (28) to protect agair^t the mis- 
use of a granted level of ayptography. The levels of 
ayptography granted are descrtoed via security policies 
and expressed as ciasses of service (26). A crypto- 
graphic unit (14), one of the ICF core elements, can be 
used to build several certification schemes for applica- 
tion otijects. The invention provides various methods 
that determine the strength of bincfing between an appli- 
cation code image and tfie issued certificates within the 
context of the ICF elements. A key element with regard 
to the exercise of a cryptographic function concerns ^e 
spedal requirements for the trust relatfon that an 
authority (22) specifies for the ayptographic unit (14). 
Any function exercised by the cryptogra|)hic unit (14) 
must be controllable by the associated dass of sen^ 
which represents the security policy. Touchpointing, 
both in the applk:ation and the firmware elements inside 
the cryptographic unit (14), plays a key role in exercising 
control over the functioning of these modules. Another 
fundamental requirement of the ICF architecture is that 
the application is assured of the integrity of the crypto- 
graphic unit (14) from which it is receiving sen^ices. 
Thus, the invention also provides methods that allow a 
determination of whether or not the cryptographic unit 
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ious classes of service and methods in connection with the use of ayptography and other features of the framework. 
SUMMARY OF THE INVENTtOM 

The international cryptography framework allows manufecturers to comply with varying national laws governing the 
distritjution of cryptographic capabilities. In partkajlar. such a framework makes it possSsle to sh^ worldwide aypto- 
grapWc capabilities in all types of information processing devices (e.^. printers, palm-tops). Within the framework, a 
ayptographic unit contains several cryptographic methods (e^. DES. RSA, MD5). 

The invention herein is concerned primarily with the applicatwn certification aspects of the fiamework. ft is a fun- 
damental requirement of ICF that an application which requests cryptographic servfces from the ICR service elements 
^''^^h some fomn of certificate to protect against the misuse of a granted level of cryptography. The levels 
of ciyptbgraphy granted are descrtoed via security policies and expressed as classes of service. 

The cryptographic unit, one of the ICF core elements, can be used fo buiW sweral cerlifii^tidn s^iot 
cation objects. The invention provides various methods that determine the strength of binding between an applicatton 
code image and the issued certif k»tes within the context of the ICF elements. A key element with regard to the exercfee 
of a cryptographk: function concerns the special requirements for the toist relation that an mjthority specifies for the 
cryptographic unit. For exanple, any function exercised by the cryptographic unit must be controlfable by the associated 
class of service whfoh represents the security policy. The touchpointing concept discussed in this document for both the 
af^lication and the firmware elements inside the cryptographic unit plays a key role in exercising control over the func- 
tioning of these modules. 

Another fundamental requirement of the ICF architecture is that the application is assured of the integrity of the 
cryptographic unit from which it is receiving servfoes. Thus, the invention also provkfes methods that allow a detemii- 
nafion of whether or not the cryptographs unit has been replaced or tanpered with. 

BRIEF DESCRIPTION OF THE DRAWIMf^ 

Fig. 1 fe a block diasRmcrf an irternattonal cryptography frameworKi^ 
unit, a fiost system^ and a network security server: 

Fig. 2 is a l)tock schemata diagram that introduces acJditfonal management elements of the ICF accofding to the 
invention; 

Rg. 3 is a block schematic illustration of the ICF and certTicalfon requirements according to the invention; 

F^. 4 is a block diagram showing the relationship of the administration elements of the ICF, Le. ADA and SDA 
according to the inventfon; 

Fig. 5 is an illustration of the dass of senHce structure according to the invention; 

Fig. 6 is a block schematic diagram that illustrates the COS level concept according to the invention; 

Rg. 7 is a block schematic diagram that illustrates toy elements in the admirv'stration process according to tiie 
invention; 

FiQ. 8 is a software architecture overview of the ICF software environment according to the invention; 

Rg. 9 illustrates tiie methods available to pass certificates to tfie sen^we provkler responsible for executing the 
requested functfons aoooiding to the invention; 

Rg. to fe a block schematic diagram that illustrates an exemplary architecture of the CU according to the invention; 

Rg. 1 1 is a block schematk; diagram of the cryptographic unit firmware according to the inventfon; 

Rg. 12 is a btock schematic diagram tfiat fliustrates the concept of a virtual CPU acoortfing to the invention; 

Fig. 13 is a block schematic diagram tfiat shows the software component certiffcation process during the installa- 
tion stage according to tiie Invention; 
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Rg. 14 is a block schematic diagram that shows the software component certification process during the execution 
stage according to the invention: 

Rg. 15 illustrates software level touchpdnts aocoiding to the invention: 

Fig. 16 illustrates instruction level touchpoints according to the invention; 

F^. 1 7 is a Ijlock schematic cfiagram showing the manufacturing stage according to the invention; 

Fig. 18 is a tslock schematic dia^m showing the installation stage accofding to the invention: 

FiQ, 19 is a block schemafe das^m of the execution stage according to the invention; 



Fig. 20 illustrates the principle of Gasses of Service, touchpoints. and envelopes according to the invention; 
Fig. 21 illustrates the memory hierarchy with respect to the software touchpoint resolution accorxJing to the inven- 

Rg. 22 shows a host syston processor fetching instructions from the memory code image of an application which 
has structured instruction level touchpoints installed according to the Invention; and 

Rg. 23 is a block sdiematic diagram that Illustrate instruction level touchpoint support inside the host system proc* 
essor according to the invention. 

DETAILED PgS CfflPTIOM QF TOE INVEKmOfi 

National ayptography policy often varies by IfKlustry segment, political dimate, and^or nvessage functfon. TTiis 
makes it diff bult to assign one uniform pdicy aaoss all irxJustries for all time. Consequently, the f lexibiRty of a cryptog- 
raphy framewwk that incorporates a national flag card. i.e. policy, is very attractive. The invention is therefore jximarify 
directed to resoMng problems surrounding international cryp^raphy. However, tfie invention is adapted to. and 
I ntended for. many oth^ applications. 

The invention preferat)ly reskies within the context of an international cryptography framework that has four service 
elements, each offering different types of sennces. Fig. 1 is a block cGagram of the international cryptogaf^ framework 
(ICF) 10. including a national flag card (also referred to herein as a >)licy card" (PC) and as a Ipoficy^ 12, a crypto- 
graphic unit 14, a host system 16. and a network security server 18. It shouW be appredated that various of tfiis ICF 
elements may be combined %wtiiin a common environment, e.g. the cryptograpftic unit and polk:y caid may reside wHhIn 
the host system For example, tiie cryptographfc unit policy card, and host system may comprise a single integrated 
drcuit e.^. in a printer. 

Host System (HS). The system or unit tfiat cwtair« a Crypfogr^fc Unit (CU), Thts elenwrt of ICF su«)orts an 
Appfication Proffamming Interface to a CU. It afeostjpports applications that are security aware and ttiatn^tf^ use 
the CU Th^ applicatwns are bound tightiy to the CU during runtime. 

Cryptograplw Unit (CU). The system or unit that contains tite cryptographk; ftmctions. These functions are dor- 
mant and cannot be used by the HS unt» activated by a PC. The crypto^afrfiic functiws induded in the CU are deter- 
mined by business demand. The CU is tamper resfetant to protect any keying material that may be stored thereia It Is 
the CU^ respoTstoility to maintain contact with a PC. Failing to do so results in tfie decay of the CU's functionality. 

Policy Card (PC). The system or unit tiiat contains autography usage policy ^aedfically this dement of ICF con- 
tains parameters that govern the use of cryptography in one or more Cus ttiat are known to this PC. Furthermore, fhfe 
element is resp(»isS)le for responcfing to the Cus heartbeat challenge. 

Policy cards can be implemented in either physical or wrtual form. A physical pdicy card requires hardware st^ort 
inside the CU. which then engages with the PC in a heartbeat relation. Hardware lewl touchpoints. the method of ds- 
abling tiie hardware cryptographic functions (see Wemba et al. Cryptographic Ur\'n Touch Point Logic, US. Patent 
Application Serial Ho. 08/685,076. filed 23 July 1996), must be implemented for a physical policy card. A virtual pdicy 
card (VPC) operates in corijunction witti a hardware or a firmware Implementation of the touchpoint techniques. In tfie 
VPC scenario, pdicy distrflxition involves the network security server. 

Networi< Security Server (MSS). The system or unit tfiat acts as a trusted tfiird party to provide networi^ security 
services to HSs, Cus, and PCs. These services can indwie pdicy enhancements, pdicy distrBjutfon. unit verif kation. 
adjustments to authorizations, and key management services. 

ICF Management Frameworic Perqsheral to tfie core elements of ICF are tfie manufacturers of the cryptographic 
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equipment and the domain authorities which implement the policy definition and enforcement through the framework. 
Fig. 2 i8 a block schematic diagram that introduces these additional management elements of the ICR 

There are tour basic elements within the administration framework. These are the Security Domain Authority 20. 
the Application Domain Authority 22. the Host System Elements 16. and the Network Security Server 18. 

The folk)wing definitions apply with regard to the discussion herein: 

Manufacturer. The manufacturer rs the actual producer of cryptocpraphic equjpmeni The manufacturer shares infor- 
mation with the security domain authority about each lot of Cus manufactured. 

Security Domain Authority The security domain authority ( SDA) is the institution which defines the security policies 
governing the domain. Security policies are presented to the other framework elements via classes of services (COS), 
Knowledge of manufacturing information allows the creation of classes of services targeted to a detemiinistic set of 
Cus. 

Appficiaitiorii Domain Authority, The Application Domain Authority (ADA) acts as the authority that aeates certifi- 
cates for the application. The certificate contains the granted classes of service to the af^licat'oh as they were granted 
by the SDA. 

Network Security Server. The Network Security Server (NSS) acts as the trusted on-line authority that manages 
policy actrvatton for a given CU. 

Host System / Application / CU. The host system on which the applications are instaHed and on which the CU serv- 
ices are used form the execution elements to be controlled by the framework. 

The two domain authorities are shown at the top of Rg. 2, The security domain authority (SDA) is responsWe for 
granting a set of cfasses of service 26 to the application domain authority. The SDA is also responsftjle for issuing policy 
cards which contain the COS information and the toucf^oint data Ibr the CU. Ihe SDA manirfactures this information 
upon request from the site which installs the CU into a host system. 

The application domain authority (ADA) receives the COS elements granted by the SDA. It has the responsibility of 
issuing applicatfon certificates 28 to applications 29 that befong to its cfomain. An applk^tion certifk»te oontawis an 
appfk»tion ID and the COS granted by the ADA. 

Applications recdve a certTicate fr^om the ADA. virhich must be presented to the CU to receive the desired COS 
level. The CU, upon receiving the request uses the c«"tificate to determine whetiier the application has the right to 
access the requested ayptographic function. If the COS requested via the application certificate matches ttie COS 
granted by the SDA to the ADA, and ^red in the policy card, the request is handled, otherwise it is not handled. 

The touchpdnt data are the information that is stored on the policy card 12, and which enable the cryptographic 
hardware for the defined classes of service. Periodically, this information is recomputed t)y the CU and valklated by the 
policy card. Any n^smatch causes the cryptographic caiDabitity of the CU to decay. 

The network security server 1 8 (NSS) acts as an online instrument for policy negotiation and changes to the policy 
information stored on the policy card. Adding a class of sendee to the set of services normally requires the issuing of a 
new policy card contairdng the dianged information. Alternatively, the NSS performs the update of the policy card on 
behalf of the SDA. 

The NSS also pfays the role of distrixition of virtual polk:y cards (VPC). VPC implementations must contact the 
NSS at defined points, eg. system starti^ to retrieve the COS information. Tf^re are COS attrixjtes whfoh defoie 
exactly when a CU must confact the NSS. 

Basic ICF Architecture Assumptions- The fCF archrtecti^e rests on a few very basic assumptions about the core 
elements. They are as follows: 

Certification. All software elements, whether they are ftf-mware components installed inside tiie CU or applications 
using the services exported by the CU. are guarded by a certificate. Any operation. e.g. the downloading of fimnware 
modules or an applicaticm for a certain level of servfoe. involves the validation of this certificate. 

Thus, one technique that is exploited to advantage by tiie invention to enhance security within tiie framework is to 
require certiffcation at various points. The use of certificates iri general is known. See. for example ITU-T Recommen- 
dation X.509(1993). 

The X509(93) certificate format is as fbilows: 
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Certificate = SIGNED SEQUENCE { 
version [OJ version DEFAULT vt , 
serialNumber CertificateserialNumber, 
signature Algorithmldentifier. 
issuer Name, 
validity Validity, 
sut)ject Name, 
subjectPubliclnfo SubjectPublicKeylnfo, 
sssuerUniqueld (1 JIMPLICIT BIT STRING OPTIONAL, 
subjectUniqueld [2]IMPLICIT BIT STRING OPTIONAL 
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Two variations in the exlstfeig X509(93) specHications are of interest in corwiection with the invention: 

• Ihe effort to drive the unique fdenttfiers across domains based on the Wefarchfeal nature of the authorities inter- 
connection, fof exarnpte in the process of vaTidatir^ a certaicate or a policy as refwred ?n Constructing X509(93) 
certificate Unlquetdentifiers from specific certificatbn system se/nanfto. Dept of Car^nrt^- ArchitectLP-e - Univer- 
sitat of Politectnica de Catahinya Barcelona (Oct. 94) (also an EWOS reference EV\«DS/EGSEC/94/183); and 
Wbrkif^ Draft for extensions to X5Q9/ISO/IEC 9594-8 certffk:ate definitkjns (Jul 94) (also an EWOS reference 
EWOS^GSEa94/168), Pblicy IDs are registered by conminity interest grot^w, such as NSA and SCSSI; or fay 
private organizatibns, such as the Software Publisher's Assodation or Rtoosolt Corp. of Redmwid. V\feshington, 

• The couplendentified poUdes and authority constraints, as referred to in Worfdng Draft for extensions to 
XSCmSO/lEC 9594-8 certificate definitions (Jul 94) (also an EWOS reference EWOS^GSEC/94/168) are well 
suited for cross^ertif ication of conpatft^e policies between governments. For exanple the locai domavi poltdes 
that the herein described dass of service is expressly recognized as supporting, once mentioned in the extension 
field, may or may not be usable with other polides as wea. and therefore fadlitates the recognition of con^tible 
poTides. An applicatfon of this aspect of a certificate is the Internet policy certification authority. whk:h could cross- 
certify a private oiganizatfon poTicy using this scheme. 



Exter^ns for the policy or certif icat'on system semantics can be found in the Uniqueld f lM su^ested by Con- 
stnjc^ng X509(93) certificate Uniquekientifiers from specific cernficaUon system semanUcs, Oept of Conputer Archi- 
tecture - Umversftat of Politectnica de Cafalunya Baicelonfei (Oct. 94) (also an EWOS reference 
EWOS/EGSEC/94/183). The Certificate Extension fields called polides field or authorityconstraints field as d^ined in 
4S Working Draft tor extensions to X509/ISO/iEC 9594-8 certificate definitk>ns (Jul 94) (also an EWOS refererwe 
EW0S/EGSEO94/168) would satisfy the second requirement 

Providing Cryptographic Functions. A system which implements the pf^cal policy card scheme, requires the CU 
to tfiplemertt hancfcwe toucfpoints. The CU does not provide the HS ¥wlti any cryptographic functions without entering 
Into and maintaining oonla<^ i«th a PC. A system which implOTents the virtual PC scheme requires tl^ presence <rf an 
50 NSS. There must be at least an inittal contact between the NSS and CU to distribute the VPC, The CU may also be 
required to cwtad the NSS on a.regular basis that is determined by COS attributes which describe the policy We cyde. 

Separatfon. Under no drcumstances can user data that is processed within the CU be accessed by the policy ele- 
ments, regardless of whether the policy card is a physical or the virtual policy card. Likewise, under no drcumstances 
should the host system have access to the policy elements related data such as touchpoint data information. 
55 Control. The CU or CUs controlled by a given PC or VPC is deterministic, i.e. every event act. and dedsion of the 
CU is the inevitable consequence of antecedents that are ind^ndent of the PC. 

ICF Basic Tmst Requirements. Fig. 3 is a block schematic illustration of the ICF and certificafion requirements. The 
ICF environment depends on a method of validating that an application 29 rightfully executes a certain level of cryptog- 
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raphy as it was granted by the application domain authority in th form of a certificate containing the valid class of serv- 
ices. A tight binding of the application to this certificate is therefore an important etemertt of the ICF The process of 
establishing this trust is refenred to as application certification throughput this document. 

Application certification descrS>es two major elements of establishing trust between the application 29 and the 
s cryptographic unit 14. 

The first part concerns the process of analyzing a piece of data to determine that it has not been tampered with. In 
general, two main classes of objects are of interest. The first class concerns the subject of program image certification. 
The second class generalizes the process and applies the concept to a variety of data objects. The characteristics of 
the CU. namely a tamper<esfstant functional unit, allow for the construction of general certification methods of aititrary 
10 data oi^ects. 

Frorn an application perspective, the application must be assured of the identity of the CU The process of estab- 
lishing this kfid of trust is referred to as CU validatiw throughout this docwnent. CU validation concerns the proc^ of 
assuring the application that the CU has not been tampered Le. it has hot been replaced with a bbguis CU. After 
the F^ocess of CU validation, the application can assume that the correct CU is perlonning the raquested ayptographic 
15 services. 

Certification of Code Images. For critical plications, there has long been a need to validate that an appircation 
has not t>een fanpered with. Performing this validation usually involves a trusted locd subsystem. A trusted load sut> 
systan is the part of the operating syst^n which is responsible for loading a program image into the sy^em memory 
space and. while doing tiiat. validating that tiie applicatioi has not been tampered with. Mechanisms, such as a check- 
20 sum over the program image, are commonly used for this purpose. In such applications, if the checksum does not 
matoh the checksum stored by the lo&der sid^system at application tnstellation time, the load fails and the program 
image is not loaded. 

A trusted loader sdjsystem cannot ex^ independently from a relationsh^) to the operating system. Trusting tiie 
loada- to validate that the application has not been tamp^ed wttii. implies that ttie operating system trusts the lo^er. 
2S A trusted kernel which is vaTidated at system boot time, usually by a piece of hardware, builds the core of the trust hier- 
archy on which the application reskies. 

A CU also includes firmware elements 27 (see Rg. 2) which inplem^ the CU runtime, cryptographk: service nwd- 
utes. and potential user level service nwdule that inplements security protocols or other user level functions. The 
requirements that apply to application certification also apply to the firmware. Thus, firmware modules which are foaded 
30 into the CU are accompanied by a f imiware certificate 25 (Fig. 2). 

Certification of General Ot^ects. Validating a code Image to determine the rightful usage of a certificate can be gen- 
eralized to validating any object governed by a certificate. For example, an fntemet applet, as they are provfoed for 
Worid Wkfe Web applicatfons tiirough the JAVA progranmng language, could also take advantage d the scheme 
described herein. Any object to be used or accessed couki be accompanied t>y a certif foate. The valuation step is very 
35 similar to the steps performed by a tn^ed toad subsystem for code images. 

CU Vatidation. CU validation descrtoes the process of ensuring ttiat the applfoatfon requesting cryptographic sen/- 
ices is assured about the kientity of the CU There are several methods which can accomplish this task. eg. : 

• Challenge the CU. In this methods tiie application issues a puzzle to the CU that only tine CU can resolve. The fact 
40 that the CU couki resolve the puzzle is proof of the identity of tiie CU. 

• The CU prepares the applk»tion to function. In this approach, the application is shqsped to the target system in a 
scrambled form. For example, the binary image could be enaypted. Only the CU whfoh has the correct decryption 
key can unscrandsle the applfoation. and hence It IS a vaiki CLi. 

45 

The second metfiod has additional applicability for software copyright schemes. Sending the application in 
encrypted form to the target side and letting the CU decrypt the program does not only reveal that the CU is a valkf CU, 
but also aflows the software manufacturer to send out an appUcafion taitored to that particiriar CU. /.e host system. 
Unfortunately, once deaypted the application image is available in the clear and can be oo^ed to other systems with 
so little or no effort 

The ICF foundation allows for a method which Is referred to as software level touchpoints and wf^ch addresses both 
the CU validation aspects of the invention, as well as copyright protection schemes. The concept of software level 
touchpoints is explained in greater detail below. 

ICF Administration Concepts. The ICF model implements a policy scheme in which the application requests a dass 
55 of services which ultimately define the level of cryptography allowed in the applfoation. The following is a discussion of 
the concepts of policy and dass of servfoe and how the administrative elements SDA, ADA, and NSS. interplay in the 
definition and distrfoution of polides. 

Polides and Qass of Sen/ice. Fig. 4 is a block diagram showing the relationship of the administration elements of 
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the ICF. /.ft ADA and SOA. The ICF is a policy driven impfenientation of ayptography, A policy is the fomnal definition 
of th level of sendee that is granted in form of classes of savic^. For example, in reqaonse to a business requffement 
to have a strong level d cryptography for an Email application, a security domain authority may create the dass of serv- 
ice "DES 128bit." ADAs asking for this strong level of cryptography are given the COS defined to implement this policy. 

The security domain authority defined in the ICF administration frameworlc is the element that creates classes of 
sendee from policies defined to meet the authorities' security interests and requa-ements. A COS has a unique identifi- 
cation. /: e. a serial nuit^r. that is not to be reused the authority, and that has to be understood semanticafly by other 
SDAs in a function of cross-certification. 

A COS 26 provkled to the ADA 22 alfows the ADA to issue apptk»&'on certtfk^ 
the COS. TN's forms a path of access control. An a^^ication nnjst have a certtficate to access the method identtf ied by 
the COS. ep. a cryptographic opaatfon at a certey 

The other fMth of control within the ICF architecAjre is the path of exfeteiKe. The COS defined must be propagated 
tothe CU to &^ble this eetvice if the path of access indicates a valid access, the riietliods labeled 

by the COS nwst be in a presort state for the request to be executed. If. for example, the C^ 
poOcy card and M policy card Is removed from the CU« the associated methods no longer exist / e. they are not oper- 
a^ng. 

Contitrf of acc^ arKl control of existence of a method are fundamental to the ICF architecture and both should 
always be present in any Inplementation. Removal of the COS from the existence path results in a non-functioning 
metfxxl regardless of the access path evaluation resuft 

Policy Activation. Policy activatfon descrftjes the orxi& of events which must take place for a CU to offer services, 
as deTtfied through the classes of senrfce. Befwe an application can ask for a COS via the application certificate, the 
CU must be activated for this partfouiar COS. The ICF is unique In the concept of polfoy controlfed activation of cryptog* 
raphy. 

D^sending on the implementation, the cryptographic un'^ must be in connection witii a policy card for the COS to 
be dowi^oaded from the policy card. The VPC scenario requires a netwrk connection to the NSS to downtoad the COS 
to tiie CU While tiiese solutions are technfcally more or less equivalent, they have a profound inplication for the trust 
model of the entire framework A physfeal policy card based solution reqiires that the CU in^ements totK:fpoints in 
haidware. The main reason for this is the detachment of control in the physical policy caixl casa A physfoal policy card 
is not necessarily connected to the domain authority environment and lesser control over the policy is possble once it 
is Issued. To conpensato for this, hardware touchpoints are placed in detenronistic locations In the hanhiare, so that a 
polfoy card cont£*i»ig the touchpoint data can t>e loaded, but cannot be removed from the inplementatfon vwthout a 
decay of the controlied applk^n. 

A fn-mware impl«nentation of the touchpoint concept operates in a ffwch more dynamic way with regard to the loca- 
tion and installation of th^ touchpdnts because the actual firmware to be toaded is not known a priori, tftus leaving 
more room for the attacker. To coftpensate for this, an on-line efemert is present in the form of the NSS. wWch al tows 
for a more dynamk; control of the firmware based touchpoint fmplmentati<^ 

Classes off Sendee. Fig , 5 is an illustration of the dass of service structore. A dass of sendee (COS) desalbes pol- 
ides- As discussed above, a policy is translated into one or more COS structures. 

Classes of service are a strudure signed by the issuing SDA 20. A COS also contains ttie touchpoint data neces* 
sary to control the touchpoint mechanfems Inskie the CU. 

• The m^hodfield 51 describes the actual method for which the dass of servfoe stands. Exanrples are cryptographic 
algorithm identtfcm. but also any other defined method such as procedures for installation of conponents or exe- 
cution rights for an operation associated wHh the COS. 

• The constraints field 52 describes attraxrtes d tfie method. Example are the attributes that govern the use of this 
dass of senflce. ag. the strengtii d the keying material used for the algorithm, the lengtti of time this COS is vafid. 
or the number of times it can be used. The touchpoint data f ieW describes the toudpoint informatfon needed by 
the CU to be activated for this COS. 

Classes of service can be nested, i.e. a COS can contain as the method part other classes of servfcesi Some 
dasses of senrtce. in particular the non-crypiographic dasses of servfoe, may not contain toudpoint data. 

Common to all COS structures is also the ocmcept of a decay poTicy. A COS can be declared to be valid for an 
unbounded fifetime or it may be linked in lifetime. Examples for a flmited lifetime are a link of the COS lifetime to the 
lifetime of th OS. th application instance, or the context established witii tfie CU. Restarting tfie OS or application, or 
dosing tiie CU context would nwk the COS as expired and invafid. Interaction with the NSS to activate the COS wouU 
then be necessary. 

Otiier evaits whfch limit tiie lifetime of a COS are counters, e.^. tiie number of operations altowed by this COS, or 
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even a single operation which is governed by this COS. The tetter is a very powerful tool for creating classes of service 
for exactly one interaction, e.g, as wouW be useful for financial transactions. 

Part of the CU implements the decay functionality in which classes of sen/ice are processed according to their 
d^y policy When the policy determines it is necessary to disable the COS. any associated functionality ceases to 
exist The ICF CU is unique in that it offers ayptographic services driven by a class of service with constraints that do 
expire. 

A special, predefined class of service, COSO. is used to guard the COS decay functionality. Because the COSO is 
itself subject to a decay policy. COS processing can be made cease to exist, thus describing the entire CU for any Wnd 
of sen^ice. A new activation from the NSS would be required in this case. 

Classes of Service Levels. Classes of service are organized not only by the object they desahe, but also by the 

^ y^'^^o? an implementation perfprrns before granting the service level descrtoed by the COS. The prefen-ed 
embodiment of the ICF defines six validatton levels for a COS. As the levels inaease, tighter validation (and therefbre 
contrd) dyer the service to be 

Fig. 6 is a block schematic dagram mat illustrates the COS level concept. The ICF in^ments several levels of 
COS validation. These levels of COS validatfon are examples only. It will be ajH^reclated that other levels of validation, 
and combinations thereof, may be provided in practicing the invention herein. They are labeled COS level 0 through 5. 
As the la^el increases, the amount of validation inaeases. Fig. 6 includes a counterclockwise circle 61 which shows the 
elements involved in the validation. At the lowest certified level, only the SOA ori^n of the COS is vafidated; while at the 
Nghest certified level, an on-line connectfon and authorization to the NSS for each operatfon is requred. 

• COS Level 0. COS level 0 Is assigned to applications to which a certificate is not assigned. Nonetheless, a mini- 
mum level of protection is provided at this level because the COS is signed by the SDA that issued the COS. This 
level is mainly intended for applications that cannot be changed to pass a certificate to the CU. 

« COS Level 1 . COS level 1 validates the COS 10 as it is made available through the applicatfon certificate signed by 
the SOA. 

• COS Level 2. COS level 2 adds to ^e COS level 1 the vafidation of the application certificate. The certificate is 
required to be issued by the ADA that asked the SOA for the COS identified by the COS 10. 

• COS Level 3. COS level 3 adds to the COS lev^ 2 the validation of the application ID issued by the ADA. 

• COS Level 4. COS level 4 acids to COS level 3 the interaction with the NSS to validate the COS requested by the 
applicaticm. 

• COS Lwel 5. COS level 5 further strengthens COS level 4 by interacting with the NSS on each cryptographic oper- 
ation requested by the application. 

• COS Level 6. COS levd 6 adds the requirement of a token, such as a smart card, fbr any one or more of the interact 
actions set forth for COS Levels 1-5 above 

Ftow of Information. Fig. 7 is a btock schematic diagram that illustrates k^ elements in the adn^istration process. 
Such elements include the appTication certificate 28, the dass of servfoe 24, 26, and the domain authorities that man- 
age them. Rg. 7 includes both a high level view of these elements and their ftow (as shown by the lines and arrows in 
the figure). 

ICF Software Environment. Fig. 6 is a software architecture overview of the ICF software environment. The ICF 
software arcWtecture descnbes the layers of libraries and system elements whfch.are needed to inplement the ICF ele- 
ments on a given host system. The foltowing cliscussfon provides an overview on the main software architecture ele- 
ments: 

• Applications, The application layer 81 is the area of user written applications and libraries wf^'ch need ayptographic 
sendees. An application may or may not be aware of these senrices. In case the applicatfon » aware, the subsys- 
tem layer 82 below offers a set of programming intertaces to the applfoatfon. Cryptographically unaware applfoa- 
tions do not issue any calls themselves, the undert ying subsystem performs these calls on behalf of the appKcation. 

• Subsystem Lfomries and Interfaces. The are subsystems which stpport cryptographic functions for aware and una- 
war applications. These subsystems also provfcle APIs to the applications. Most notable APIs include the Micm- 
soft CAPI ftx- the Microsoft workJ, and the XADpen GSS-APf and GCS-APi for the Unix world. Subsystem libraries 
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typicafly organize themselves into application programming Interfaces and, shielded through the operating system, 
a cryptographic service provider module 

The sul)system litM-aries may also hide th security APIs completely from the application. This allows existing appli- 
cations to take advantage of the solution without t)elng nwdified. An example is the integratiOT of the security fea- 
tures into transport level software sdasystems. 

Other elements of tftis layer may provide APIs for accessing the CU secure storage and execution facilities. For 
example, a database API such as the ODBC interface could be oHered along with a data manager module inside 
the CU to provide a tamper resistant database. 

• Operating Systems and Drivers. The <^)erating syrtem 83 perfbnns two fximary tasks. One is to folate the subsys- 
tem programming Interfaces from the cryptographic service providers. The other task is to provide the necessary 
hardware control through a set of drivers 84 which interface with the cryptogiaphic hardware in form of hardware 
drivers. 

• Cryi^ographic Unit Subsystem. This layer contains the hardware impfementatbn and firmware elements of the 
cryptograprtc functions 86. The hardware is typically provided in several form factors, such an PCI ca«l or a PCM- 
CIA card, to acconwiodate the diff^-ent hardware f^tfbrms and performance requirements. The firmware is a set 
of ISMaries which impliem^ a micro kernel runtime, the iCF frjnctionality, as well as user downk)adable software 
modules required by a particular application programming interface. 

• Administration, The adn^rarfration elenent 86 is responsilrfe for providing a management framework of the entire 
solution. This includes, for example, middleware oompon«its for ^minisfrative functions sudi as certificate man- 
agement application dass of service man^ement. and downtoading of applk;ation specif k: extensfons to the CU. 

The k^ elements are divkied into two groups: host system software and cryptographic unit ftfrnware Between the 
two mejor btocks is the d^inltion of a commarKt set which is used to communfeate requ^ts from the host system to the 
cryptographic unit and vk;e versa. Each of the main eiem^its is descrSjed in more detail below. 

Host System Software. The host system software consists of applk:ation level programming interfaces, system level 
drivers, and utifity jwograms which h^ in configuring and managng the subsystem. This portion may look different 
depending on tiie tanget platform and interfaces selected. 

Siteystem Ltoraries. Appffcatlon uses the cyyptographfo unrt through (me or many APIs. APIs may already exist, 
new ones are beng proposed as "standards/ yet otiiers need to be devdoped to take advants^e of the full capabilities 
of the cryptographic unit An exanple would be the ability to downtoad and execute codedynarrocally in a trusted envi- 
rorvnent. 

The cryptographic unit operates in corijunctfon witfi a wkle range of programming interfaces. AP Is may also be hkf- 
den from the applicalfon in form of subsystem libraries or mkkfieware layers which mask the cryptofip-aphk: operations. 

Host Driver, The host system nwst integrate tfie cryptographic unit into tfie operating environment From a scrftware 
perspective this includes the device drivers and any configuration software needed to in^l. configure, and manage the 
policy card. 

Management Utilities. Utility software is respons^e for installation, managen^ and configuratfon of the crypto* 
grapNc unit subsystem. It is ateo necessary to provkte utifities for devefoping servfce modules, and utilities for down- 
ioacting tfiese modules hto the cryptogrc^k: unit. 

Cryptograph^ Unit Command Set. The host sy^em software coimuinicates witfi the cryptographic unit through a 
set of requests. Examples for requests are the download of a sen^fce library or the encryption of a data buffer. To sip- 
port mult^)le platforms wth the same cryptographfo unit, the command set shoufo be the same and have the same for- 
mat for aH target platforms. The main ben^it is a single implementatkm of the cryptographfe unit software fayers. 

The oormiand set itself can be cfivkled into main categories. The first category offers conmiands which n«p to the 
available functionality of the cryptographic unit such as the executfon of a hash algoritfim. The second attegory con- 
cerns commands between the host software and tire servk;e teyer software inskle the unit. The content of these com- 
mands is largely inknown to the firmware and they are routed to the appropriate servfoe layer. 

ICF Application Programming Interfaces. The ICF introduces the concert of pdky driven ayplography. Applfoation 
programming oit^ces allow to select the desired sen^k:^ based on the application certiffoate granted by the ADA. 
This is in oonfrast to the currentiy available cryptogaphk; progranmting interfaces. Most of the cun-ait crypto^aphic 
APIs are buift around the concept of a cryptographk; context Applications establish this context before they can i«e any 
cryptographic service. No linkage is done between the application and the dass of service offered by the CU. For exam- 
ple, the Miaosofl CryptoAPI, offers a prog-ammir^ interface wWch allows the user to select the cryptographk: senrice 
provkler (CSP) typ and load the software mockile into the system. Thereafter, an application can make calls to the CSP 
and use Hs servfces. There are. however, no metiwds to distinguish cryptograpWc functions based on what th appli- 
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cation is doing. 

ng. 9 illustrates the methods available to pass certificates 90 to the service prwider 91 resporeiljle for executing 
the requested functions. There are several methods for maWng the certif icat available to the cryptographic unit. e.^^. : 

• Certificate passed in each call. The certificate can be passed in each call to the CSR This scheme allows for an 
appf ication which may pass more than one certificate or the task to be accomplished. For exanple. if an application 
*s allowed to use strong encryption for f inandal transactions and at the same less strong encryption for E-mail func- 
tionality, that application can select dynamically the level of cryptography by passing the corresponding certificate. 

• Certificate passed at initiafeation time. The certificate can also be passed when the link to the CSP is establtshed. 
An application using multiple certificates could establish mutt^e contexts, one for each certiffcale, and use the 
appropriate one in the cryptographic function calls. 



• Certificate irr^idtiy available. The certificate is transparent to the application and available to the cryptographic lay- 
ers. For example, the applicatton passes its name which is used to index into a registry tftat contains the certificate 
K>rtf«*8applk:ation. 

All of these methods rest on the assumption that tfiere is a tight binding between the application and the certificate 
This concept is referred to as application certif k»tion throughout this document As discussed bebw. the CU plays a 
crrticai role in establishing this tight binding. 

jCF Cryptographic Unit, At the cae of the f CP framework is the CU. An implementation of the CU provides a set of 
sennoes to tiie host systentThese services indude cryptographic functions but also other functions, such as storing 
sensitive information that take advantage of the tamper resistant characteristics of the CU. The fdllowing three broad 
categories of 6er>m;es are offered by the CU: 

• Cryptographic ftjnctions. The main purpose of the CU is to piovkfe cryptographic functions. The unit hosts hard- 
ware and software to canies out tfie defined cryptographic algorithms, ft also hosts hardware and software which 
enforces a certain crypto^aphlc policy. 

• Secure storage. Secure storage allows tfie CU to store information in a secure manner in^e the CU. This fedlity 
IS pdmarily used for the storage of keying material inside the CU. Over time, application and subsystem layers may 
also take advantage of tf^s fecility by storing other non^ecurity related material inskJe tfw CU. 

• Secure execution. The CU altows for tfie execution of code in tfie secure and tamper-resistant environment of tfiat 
unit. Applications and subsystem layers may take advantage of this fecility to implement a portion of their function- 
ality, such as security protocol handlers, in this secure environment 

ICF Cryptography Unit - Hardware. F^. 10 is a btock schematic diagram that illustrates an exemplary architecture 
of the CU Rg. 10 does not refer to a partkuilar physfcal implementation, but rather shows the main elOTents needed 
inside the CU to irnpl©nent the three broad categories of functionality outiined above. There are several comoonents 
which form the CU: 

• Central Processing Unit The CPU 101 is the heart of the unit controlling all infbrmation ftow. Modules downtoaded 
for secitfe execution are executed by the CPU. 

• Storage Elements. The CU 14 needs several storage elements. The Flash memory 102 is the storage area for pro- 
grams and nonvotatile data stored in the CU. Ihe ROM storage 103 hosts the bootstrap code which executes on 
reset of the CU. The f^AM storage 1 04 hoW the volatile cteta of the C U. 

• Cryplographfc ASIC 105 and Random Number Gtenerafor 106. These tvw elements perform the basic operation 
operations for the cryptographic functions offered by the CU. Fa implementations which provide touchpoinfs in 
hardware, ICF touchpoint logic for enabling these functions in the presence of a policy card can be found in these 
elements. 

• Bus Logic. The Bus fogic 107 inteifaces the unit with various other interfeces to the host system. Two main chan- 
nels exits towards the host system 108. TTie first channel. Le. ttie control channel, is used for commands and status 
messages between the calling system and tite CU. The data channel carries out the actual data transfer. 
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ICF Cryptojpaphic Unft Rrnwara F^. 11 is a block schOTatic diagfam of the cryptographic unit f v mware. The CU 
firmware 27 is the software which resides inside the ayptographic unit U. There is a core runtime nxxlule 113 which 
controls the overall operation of the unit kernel s&^nces layers 112 which irrpiement security polkaes and control 
access to the o^rtographic functions, and service Itorary modules 1 1 1 which closely interact with the hosts system 
applk;ations to inplement application specif k: security sendees and policies. 

Thefirniware components can t>e dvided among a sharp line which is called the trust boundary 115. Below the 
tnjst bouTKiary. the CU core runtime and the actual hardware can be found. Above the trust boundary, the CU runtime 
managing the ^e chf> and ii|3per level sen/tce modules can be foiffid. 

CU Core Runtime. TTie CU cor© runtime implements the tow level servfces wWch shiekl the underlying hardware. 
It also offers sendees to the support layers to manage tfie resources offered by the CU, eg. memory ot^ects for code 
modirfe stOTB^. The CU core mntime s responsit)le for the COS processing. Each operation requested by the upp^- 
l^ers is acconparied by a COS ki&^ier. The COS decay pofK^y is implemented below this boundary. The CU core 
runtime prelection rests wthe foltowing key 

• ROM Code. All CU core runtime code is in^emented in ROM storage. Ben^iting from the tanper resistant nature 
of the CU. this code cannot be manipulated nor bypassed The ROM is mapped into the CU processors address 
space to cover the reset and hardware interrupt vectors such that any reset attenpt forces execution to be inside 
the TOM code boundaries. The ROM code runs at the highest privilege level of the CU processor. 

• Protectkwi Ardiitecture The CU processor is required to implement at least two privilege levels. Menwry djjects 
aRocated at the higher privilege level cannot t>e accessed by code running at a lower privilege lev^. This boundary 
ts enforced by the CU processor hardware and cannot by bypassed under any circumstances, 

• Persistent Storage. The CU core runtime reqwres a certain amount of nonvola^e storage atfocated at the highest 
privaege level only accessible to the ROM cocte. This storage is used for the C^^ 

processing, as desaibed in greater detail betow. 

AH code introduced above the trust boundary is sut)ject to toucl^'nt processing. The concept of fouclpoint 
processing ts discussed in more detail below. It Is atportant to note that code above ceases to fiffiction if the touchpoint 
locations are not res<^ed by the cae runtime during executfon of thte cod& 

CU Rimtime Servfoes. The CU runtane services provkles the elementary operating system functions needed to 
n«nage and organize the card. It reskfes directfy on top of the CU core runtime. This ojntime may be thojght of as a 
micro kernel which runs at high execution privUege level. This kernel is tiie only place which drives the crypfographk; 
functions avaifabfe for the higher level service modules. The fottowing bask: capabHrttes shouW be available: 

• Secure Loading. Due to the nature of the unit, some software module foaded into the CU need to be validated 
before they can be foaded and executed. At load time the loader loads the code image and, if required, validates 
the signature of these modules. The secure foader is part of the kernel code and part of the CU core runtime. The 
kernel code itself foaded and vaikfated by the CU core runtime module. 

• Memory Management The memay manager of the n^'cro k^el is responsible for allocatfon and deafloc^^ 
main staage. Memory can be aitocated at the different ring levels to ensure protection between the memory areas. 

• Tasking. The task handler provides the basic mechanians for rmning multif^e tfveads of operatfon. Incoming 
requests may trigger the start of a new task or are sinply queued for an existing task to serve. 

• Internal Message Facility If it is desired tfiat the foaded nwdules need to communfoate witfi each other, some basic 
form of ffiter task oonvnunfoation must be provkfed. 

• Crypto Paging. Crypto paging allows the memory manager to allocate storage outskte the cryptographic unit 
boundary and store pages in encrypted form. This facility is needed if the amount of storage needed inskie the unit 
exceeds what is available. 

Access to internal Resources. Most of the otiier components, such as the cryptographic hardware on the chfp^ are 
accessed tfirough routines that are part of the micro kernel. 

External Interfaces, The cryptographic unit interfaces with tfie host system through this conponent, whfoh is the 
aitry point for an external requests. Th requests are passed accordfrig to the d^ined command set are decode 
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and passed along to the appropriate untt (or execution. This layer may be d^endent on the type f host system 
txjsardiitectufe. 

CU Services. This set of libraries runs at the least privileged protection level. This level hosts libraries which could 
iiTTplement sendees for a given programming interlace, such as the ICF Envelope APIs, cryptographic APIs, such as the 
Miaosoft Crypto API or the xrapen GCS API. or any other APIs as needed to offer an abstraction 1^ 
seoire execution, or downloading facilities. Commands exchanged between the host system and this layer are defined 
by the mplementor of this layer. 

The service libraries layer also offer the possibility of allowing an application to execute some portion of itself in a 
secitfe and trusted environment. This fadlity could be used to implement copyright schemes, or special functionality 
suchas nskevaluationmodul^forfinandalap^ The 
host system dnver passes the information between and the application an the service libraries as messages. 
A Virtual CPU. Rg. 12 is a Wock schematic diagram that illustrates the concept of a virtual CPU. 

Another way to look at the finrware structure discussed above is to combine the lower level finnware found in the CU 
core runtime and flie underlying hardware into a virtual CPU executing under the constraints inptemented by this oom- 
liination. 

It'c !Jir ^ ® processor capable of executing instructions under the control of a poUcy. Part of 

««8ICF CPU IS concerned with the COS evaluation and the resulting touchpoint resolution process. Looking at the 
combination of the firmware and hardwrare elements as a joint unit allows a better descr^Jlion of the trust model and 
evaluation of a hardware /finnware oombinatfon against it Once this compon«it is validated, analysis of any module 

loaded and ajcecuted on top does not have to be evaluated with all the tower teyer irteraction around t^ 
memory protection intemnixed. 

AnyP»VSicalprooessormodel/ROMcombinationwhichcanimpleni«rttheprotectionm^ 
IS therefore capable of being configured as a virtual CPU, as may be required by the ICF CU arcWteclure. Any module 
written for such an ICF CPU can oin on any ICF CPU that passes the strong security requirements. 

Software Compcnert Certification Process. Software ojmpon^ 
IS a tight binding between the appCcation im^e and the application certificate Issued by the ADA. It also bidudes 
firmware components and firmware certificate issued by the SDA. 

The process of software componem certif icatfon can be desaibed in two distinct stages. They are the installation 
stage and the exBcutfon stage VWienevw the term application is used in the foltowing text, ft shatt also include the 
fimiware eonponents. The toBowIng is a brief desertptJon of the certification process ste^ 

• InstaRatkm stage The installa«on stage descriies the steps necessary to introduce the awjfication and the accom- 
panying certiricate to the CU. 

• Execution stage. The validation stage describes the steps taken to validate the applications identity based on the 
certificate passed atong with the validation request After successful validation the cppUcation enters the executfon 
stage. At any lime during this stage, the CU can issue a validation request to revalidate the application^ daan. 

Installation Stage. Rg. 13 is a block sch«Tiatfc diagram that shows the software conponait certification process 
dunng the installatfon stage. Certified Applicafions are introduced to the host system at the appiicatfon installation 
stage A certified applicatiai con^sts of the appiicatfon image 29, i.e. the code f 8e. and the certificate 28 issued by the 
appficatton domain authority. The resuKoftheinstaflation stage is an appBcationaedential 130 which uniquely denotes 
the appiicatfon, the CU. and the vaiW classes of sennces. This resutt is rtfened to herein as an appKcatfon credential. 

The pupose of the install process is to introduce the application 29 to the CU 14. A special utility program, the 
install program 1 35. is called to cany out the necessary work. The main task of this utility pertbrm is to pass a reference 
to the program image and the appflcatfon certificate to the CU. The CU upon receiving the request for installation uses 
Its host system memory access capabilities to compute a hash value from the program image 

The application certificate contains, among other in«onnation,the application ID 137 and the dass of service 136 
ddined far this application. Using these two elements of infomialion. the CU produces a aedential which identifies the 
appBcatmn, e.g. through a name the hash value of the appiicatfon image, and the dass of service defined for the appli- 
cation. ' ' 

The credential is then signed 138 by the CU and stored in focal non-volatile memory inside the CU If desired the 
credential could also be exported to an external area. Because the aedentials are only useful to the CU that generated 
thenr it orty needs to be ensured that the aedentials have not been tampered with white outside the CU boundaries. 

Execution Stage Rg. 14 is a blodc sdiematic diagram that shows the software component certification process 
dunng the execution stage. In the execution stage an appfication 29 is loaded by the operating system into the memory 
system and starts execution. At some point in the appifoation execution., the application requests cryptogn|)hic serv- 
ices. Normally, the f iret step is to establish a context with the CU An application passes the application certificate 28 
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issued by the ADA to the CU 1 4 wtien it establishes a logical associatioa eg. a cryptographic context 

l*on receivir^ the request to estat^ish an assodaton. the CU validate the identity of the application based on the 
certificate passed. Through the operating system components, the CU has access to the a«)iication image and is 
th^efore able to compute the signature of the application. For example, using the DMA capabHity and the knowledge 
of the memory «idress range of the application within the memory syst»n. the CU can conpute a hash value. 

After vaSdating the con-ectness of the certif icate. the CU uses the certif«ate to locate the application credential 1 30 
corresponding to the certificate. The credential contains, among other infbmiation, the conned si^iatire 138 of the 
appRcation image from the installation process desatoed in the devious siteectkm. If the values match, two Inportant 
facts can be deduced. Ftfst, the application's identity is established because the conputed signature over this image 
matches the computed signature at installation tima Second, the application has not been tanpered with since the 
installation stage. 

Aft^this initial validafem step, the aj^icationca^ Atany 
time later on. the: CU may decide to execute this validation><x^ again. The options range from vsilidating on a perf- 
odk; basis to va&iating ipon each reqt^. 

J=fom an opmtmg systwn perspec^e. no changes to the loader and the cpemting system are required to inple- 
ment tiis scneme. The only requrements needed are the ability to access the memory image of an object Implemen- 
tatkjns may however decide to invote the CU at appTwation load time to f^rfbrm the valkJatton step. 

CertTcation of Fimiware Components, Firmware certificatfon is not fundamentally different from applicatfon level 
c^ication. Both share the elective of establishf^ 

difference that can be seen fe that the tower level firmware objects are certified by the SDA ratfw than the ADA. High 
level firmware (Meets, e.g. user written protocol modules whfch are <townlo«Jed to the CU. are certified by the ADA. 

Another difference is that any firmware module downloaded into me CU. whether a user written high level module 
or vendw sifplied lower level module, is subject to the toucfpc^ng process. Ttus process is optional for application 
otjjects outside the CU boundary, TTie ftHichpdnting concept is described in greatw detail below. 

Certification cA General Ot^ects. TTie scheme described in the previa^ subsection can easify be extoided to cover 
not only code irmges but also any Wnd of <feta object wt^chcoj^ validation method aitlined. For 

exanple. the operating system itself. sirf)system Ifcran'es. and state conf Igiratton tnfomiatlon could be protocted from 
unauthcwTzed mocfifications or replacement by th« schema 

Software Level Touchpoints. Rg. 1 5 i llustiates software level toudpoinfs. ICF Softwam touchpoints are areas of 
date ttiat are not usable to the host or CU system envfronn^ until prepn^ 
point IS that of tfisfruction 6equ»K»s In a oxf e irnage %vhk^ 

wit of the processor canrKrt decoded them successfufty. Similarfy. there coiid be date areas whldi have been altered 
in a way that the original date is notaccessfele. 

A software touchpdnt is diaract^ized by a starting address within the addr^ range 1 50 of the o^ect 1 51 and the 
length of the touchpomt There are several dasses of software toudpoints. Date level touctpolnte descrftje an area 
lnskJeadateot^ect^toftfftherflrlformat^onabouttheTa A 
separate derta area describes these touchpoints outside of the date ol^ect. 

Insfruction level toudpoints descrftje toudpoints inside an ir^truction stream. There are two sub dasses. The f rst 
sUKlass descrfces instmction level toudpointe similar to their date level counterparts. In this case, an area in the 
instruction stream is replaced by tfie toudpoint intwrnation. The second sttelass descrajes instmction levd touch- 
pointe that have a structira A structured toudp<»rt starte a^ 
toudpoint area. All these types of touchpoints are descrl>ed \n more detail below. 

Instruction level Toudpdnts. Rg. 16 illustrates Instn^tton level toudpoints. There are two type of instruction level 
touchpoints. The first type 1 60 inplements an instruction level toudpoint as a date area in the instruction stream which 
has be replaced by a scramWed version. No further infonnatton is available about the toudpoint at the tocation itself. 
ThesecomJtw)€l61 implements the toiKipoim with a distinct inslructfon at t^ 

of the toudpoint area. To disfinguish the two toudpoint areas, the first type of toudpoint is refen-ed to heran as an 
unsfructured toudpotrt. wf«le the second type of a touchp<*Tt is referred 

Mechanismsforlnplementinglnst^^ 
of software level toudpoints. Depending upon the processor used and the hardware support available, toudpoints can 
be iirplemented in a variety of ways. Common to all irrplementations are the fd towing aspecte. 

• Resdvfng the Toudpoint Resolving a toudpoint can be done In cfifferent ways. For exan^e, a p.stert and 
tp.end insfruction could demarcat a toudpoint area. The infomiation in between is the toudpoint date to be 
transformed to the original instructton sequence. In the case of an instruction level toudpoint the date in b^een 
are insfructions. The demarcation instruction could frap to the CU to resolve the toudpoint area and put it back wito 
place again after the instajction sequence has been executed. By tftis. it ensures that with the exception of oper- 
ating system ejccepttons. no other code can be executed which could have access to the toudpoint area. 
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Atternatively. one could implement this touchpoint decoding function inside the instruction fetch unit of a CPU. A 
policy register oouW store the necessary decoding key for this application on context switch. Benefits of this 
approach include the transparency of the TP, comt»ned with the benefit of maWng the code unusable for another 
system. This alternative is discussed more in connection with the discussion below of host system support fbr soft- 
ware level touchpoints. 

Resolving a touchpoint can be done in a way that the toucfpointed area is uses a mechanism fbr ensuring only the 
recipient. Le. the one which can remove the toucfpoint permanently, is the con-ect recipient for this touchpointed 
ol)ject Resolving a touchpoint can also be done in a way that the toucf^nt stays in place and is resolved only for 
the duration of the usage of the touchpoint area This approach is used to inplement the existence criteria of meth- 
ods inside the CU, It is critical to leave the touchpoint areas permanently in place. 



• touchpoint. A touchpoint r^ces a sequence of instructions. Ihe Inplemartation must provide 
an ©cecutidn object in which the original instructions are to be executed. The sequence of instructiorw should be 
executed atomically. The sequence of instructions iteelf has to safi^ certa&i criteria. f=br exanple, branches out- 
side of or into a touchpoint area require substantial support from the processor to detect when someone is inside 
a touchpoint area. However, for strengthening the mechanism, this alternative fe worthwhile to pursue. 

There can be a very few or many toudtpoint areas in a code object f=mm the set of possit^e touchpoinis. an er^e- 
mentatfon can select at runtime a random set of locations to toucfpoint Also, to strengthen the toucf^soint concept 
further, the set can be modf ied dynamically, Le. towrfrpoints are added and rwiwed randomly from the set. Tlife 
defeats an attack in which one oouW locate the toucf^nt areas and over time detormtne me oritf nal instructfon 
sequence. 

• Defecting a tojchpoint Detecting a toucfpointed area requires a mechanism whfch allows the fwocessor to detect 
«^ start and the end of such an area. R)r fouchpdm areas that contain branches 

with such an tfKficalioa The processor's trap capabilities can be used to implement any of these mechanisms. The 
range goes from using a software btfenrtpt InstnjK^tioa over illegal operalton codes to force an execution, to dedi- 
cated Instaictfons such as the tp^start and tp.end Instruction mentioned above* 

Data l-evel Touchpoinis. As vwth the uns^mctired instruction level toudpoint any fond of constant data can be pro- 
tected ty this scheme. If the processor stpports a date breakpc^ mechanism, these areas can be located during the 
execution and resolved In a shnilar manner as the instniction level touchpo^. 

CU Validafion Process. Applications must be assured about the con-ectness otf the CU The ot^ective is to avoid the 
scenario In which someone recSrecfs the application requests to a different cryptograpf^ functfon. The CU validation 
proc^ descrtoes the steps taken to assure the applicatfon about the identity of the CU. The valkJafion process 
desaft>ed in this chapter uses the software level toudipoinfs as the main concept used. CU vaiidatfon can be described 
in three cfistinct stages: 

• Manufacturing Stage. The manufacturing stage descrfoes the steps that must be takm at the application manufac- 
turer side to aeate an application having the software level toudpoint inlwnialion incorporated therein. 

• (nstallat'on st^e. The installation ^age describes tfie steps necessary to introduce the applk»tion and the accom- 
panying certificate to the CU. Depending on the type of installation, the software level toucfpcwnts may be removed 
at this sta^ or left intact within the application image to be resolved at execution time. 

• Execution stage. The validation stage descrftjes the steps taken to validate the applications identity based on the 
certtf icate passed atong with the validation request. After successful validatidrt, the application enters the execution 
sfage. At any time during fhfe stage, the CU can issue a vaiidatfon request to revalidate the applicatfon's daim. In 
addilfon to these appScation certTfcatibn steps, the software level touchpoints Installed in the applfoation must be 
removed or transformed dynamfoa»y as they are encountered by the host system processor. TWs is only the case 
if they have not been removed during the installation stage. 

The CU validation process outlined below allows for additional benefits that go beyond the main goal of CU valida- 
tiofi. From a software manufacturers perspective. Issues concerning copyright protection are becoming Increasingly 
aitfcal in a networtc worid. A software manufacturer therefore wouW like to be assured that the software shipped to a 
customer Is not copied to another system. The range of requiremente can rang from ensuring that the software is 
loaded to only a vaiki group of authorized systems to customizing the software fw exactly one system. 

Manufacturing Stage. Rg. 1 7 Is a bfock schematic diagram showing the manufacturing stage. In the manufacturing 
stage, the applicatfon 29a is produced by the application manufacturer 1 70. The objectives are to build an application 
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which can be tailored for the particular group of target systems or a single target system. The target system is identified 
by the CU instafledinit 

The applicalion manufacturer first develops the applicati<»i. This is the executable veision of the appTication for the 
target host system platlbrm. Before the app{k:ation can be dipped to the target host system, the custorraze step 1 71 
installs the software level touchparts. After the ir^tallatfon. the application 29 can be shipped. TTie customize ccwpo- 
nent shown bi Fig. 1 7 is responsible for instalRng the touchpoints in the application image. 

The ADA 22 is the domain authority in which the application manufacturer resides. The ADA is granted a dass of 
sennces by the SDA 20 which define tf^ function used to install the touctpoints ffito the application image. 

One part d the touchpoirt instaUatton Is to produce a list of loca^ 
code image. In the case of ur^taictured instrucfion level toudpoints. th« information needed to locale the touch- 
P^"^ ^J^^^^ f':*stmdion level fpiKJipoirite, this information is not stric^ necessary. There are alsa considera- 
tions cofw^rng exactly where a toucfpotnt could placed am^ what the length of such as sec^ence should ba 

Fdrunsfifi^edtdu^ 

tanc». Technicaiy they can be placed into any area of the image. For structured touchpoints, there are more constraints. 
Reactions inckde ihat touchpoints should, for example, not cross procedwe bouncfaries. or overtay more than one 
basic block of instructions. The restricttwis d^send on the nature of the hafxlware level siwort for structured touch- 
points. Some of tfiese aspects are discussed elsewhere herein. 

At the end of the mamifacturing st^, there is an application image augmented with software level toudpoffrts 
1 72. The touchpoints were put into the «nage in a rightful 

the CU for the customize oomponert was granted this right by c«1ff ication from the SDA to the applicatwi manufacturer 
ADA. This process, so far. does not involve information about the target system. Any installation virhich has the capabil- 
ities to reverse the touchpwirt infoination Install process can derive a worWng apf^k:atioa 

A further taitoring down of the target system requires additfonal knowledge about this system. Because this ftifro- 
duces a tights dependency between the manufacturer and the target recipient, a higher effort Is necessary on the 
adnmistiation side. 

Inst^fafion Staga Fig. 18 is a btock schematic dfagram showing the insfaflation stage. The installatfon stege 
describes the steps taken at the tafget site, /.e the host system and a specific CU 14 are necessary to prepare the 
appficalion 29 for i^e on system. Agaia there are several ot^ectivea The f iist dbiee^ is to ensure that an appli- 
cation is assured about the irtegrity of the CU. This assurance Is achieved by that fact that only a CU which was granted 
the necesMry COS to process tfie appifoation image is able to successfully transform tfiis nnage into a usable one. The 
second ot^ctive Is to ensure ihat once an application is installed on the target system it is only usable by this system 
OTd cannot be copied to another system. 

The instalter componait 180 is responsSjIe for installing the application in the targ^ system. As a part of the install 
process, the appGcation's aedentiai 28 whk:h descrtoes the COS 26 avaif^e to the application is created. The details 
of this piocess are descrftKd n greater deteil abova The other part of the install 
to prove that this is a valid CU and to bufW an appRcation image whkrfi ^ 
the CU that was used by the in^ fmcess: 

The SDA 20 giants the ADA 22 the set of COS 26. The ADA grants the ^Icatfon rights to a set of COS. The policy 
card 1 2 cortiakts the valid COS for the ADA and the COS for the insfalla- as it vvas gmrted to the ADA of the appllcatfon 
manufacturer. The instaOation component can therefore only process the toudpointe in the application image if it was 
granted the COS to do sa 

Toudpoints can in theory be removed at the instalfation stege. However, removing them ftwi the application fenage 
at this stage has two consequences. Rrst the appllcatfon has only a one time assurance that the CU is a valid CU at 
installation tme. After the removal of toudpoints amrther CU could be installed along with another policy card or be 
bypassed when the ^ication requests cryptographfo services. Second, without the touchpoints the application is in 
the dear and can be copied and executed on any other system. To prevent these scenarios, the toudwoint should be 
removed as fate as possfole in the execution cyda 

Execution ^ga Fig. 19 is a btock schematic dfagram of the execution staga In the execution stage, the applica- 
tion runs on the host system. The operating system loader 1 90 transforms the application file image into ttie executable 
memory imaga One part of the process conc^-ns the requirement of vaTdat'ng that the application has not been tam- 
pered with since installation time and rightfully requests a certain dass of servtea The steps taken to ensure this have 
beendescrfoed above in connectfon with the discussfon of application certiffoatfon. For the CU vaOdatfon portioa addi- 
tional steps are required. 

At. wficatJon load time two main ot>ja:tives need to be addressed. The first (Ajedive fe to validate the CU. This 
task IS acoonplished if the CU is able to resdve the software toudpoints from the applicatfon. For. exanple if the CU 
is able to compute the original signature of the appllcatfon without the touchpoints. it proved that it can successfully 
remove them and is therefor a valid CU because it was granted the COS to perform tWs operatfon. The second objec- 
tive is to resolve the touchpoints. The CU is responsfol for removoig the touchpoints before the application portion that 
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contains them is executed. 

The sinplest case is for the CU to remove the touchpoints from the application code image. The file image of the 
program wouW stiti contain the touchpoints and stays iseless if copied to another system. The memory portion is how- 
ever in the dear and could be copied if a malicious user would write a copy program which constructs the file image 
from the memory image. Such a task requires some sWIIset and knowledge of the underiying operating system, but is 
not impossible. 

Another approach is to leave the touchpoints in place and resolve them as they are encountered. This approach 
relies on some hardware support to detect the touchpoints. This is desaa3ed further in connoA'on with the discussion 
on hardware support for software level toucfpoints herein. 

Taloring to a unique CU The process desaibed so far does not establish a close relation between the software 
software component and ttfie target sysftem identified by the CU installed in it The benefit of the rather 
loose coupling permits the manufacturer to produce an application wWch can be installed on any system that has the 
capability to process the touchpoints installed inside the application. No further knowledge about the target system is 
required. 

If a more tight binding desired, the application manufacturer needs to tailor the application component to the tar- 
get system CU This could be done, for example, by creating a unique COS which is shared between the manufacturer's 
ADA and the SDA, The SDA installs the unique COS on the policy card when it is customized for the target system CU 
and shares that COS with the ADA of the appfication manufacturer. Only the installation utility on the target system 
which is granted that unique COS can successfully install the software m the target system. 

Firmware Touchpoint Support in the Cryj^ographk; Unit. Rg. 20 Illustrates the prinqple of Classes of Service, 
touchpoints, and envefopes. Firmware level touchpoints are touchpoints mtailed In a firmware module which resides 
Inskle the CU. As such, they must be controlled by the ICF CPU descrft>ed in above. There are three bask: btocks of 
functionality whidi the ICF CPU must provkJe to handle firmware level touchpoints. 

Rrmware touchpoint processing involves three bask; conponents if the ICF CPU: 

The first block is envdope handling 200. Policy activation, ie. the process of sending the appropriate information 
to tfie CU to activate a certain class of servfoe. IS commiffticated between the NSS and th^ 
as they are desaibed in the ICF architecture. Before any furtiier processing of these envefopes takes place, their origin 
and vaHdity needs to be venfred. 

The valkiated and autiienticated content of the envetope is passed on to the second conponent whkrfi is tfie COS 
engine 202. The COS engine can be seen as the heart of managing the classes of servwe installed on tfiis CU. Each 
request for a service associated with a COS is directed to tfiis engine and evaluated for access control to tins resource. 

In addition, the COS engim also maintains a heartbeat fonctfon wNch aflows inplementation of COS decay. Peri- 
odkafly. tfie COS engine analyzes each COS staed and verifies that the boundary concBtions for this COS are still tme. 
The bounctery conditions are also evaluated for each request if the COS attrilxjte specifies it For example, a COS which 
specifies tfiat only a certain number of operations are allowed invokes the engine evaluation mechanism on each 
request and decrement a counter. 

The third basic component is TP Resolution 203, The TP resolution btock is respon$i3le for handling tiie resdution 
of touchpoims 204 as they are encountered by the executing f tmiwara Through one of the mechanisms ouffined earlier, 
control of executfon frarrefers to this conponent and the i n^ructions whfeh are masked l>y the touchpoint are executed 
within the tnist boundary 205 established by the ICF CPU Once the COS engine determines tiiat a COS is no tonger 
accessWe, the COS is marked invafid and the TP resotutfon process does not function for this COS. As a resiA tfie 
firmware can no tonger t>e used. 

Host System Hardware Support for SW Touchpoints. Fig. 21 Illustrates the memory hierarchy witfi respect to tfie 
software touchpoint resolution. Software level toudipoinfs can take advantage of hardware support.from tfie host sys- 
tem CPU. A key aspect of this embodiment of tfie Invention brings the resolution process of touchpoints ctoser to tfie 
host system processor execution elements. By moving tfie resdutfon process close to tfie processor 210. e.g. tfie 
cache subsy^em 21 1 , no tou^f^int areas in tfie clear are in the main memory system 212 or storage elements 213 
at a lower level in the memory hierarchy. 

In this embodiment of the invention, tfiere are two main approaches for resolving software level touchpoints. In tfie 
first approach, the host processor generates an exception tpon detection of a software touchpoint which invokes tfie 
CU to resolve tfie software touchpoint The second approach is fairly similar, exc^ tfiat is uses tfie host system 
processing elements for tfie actual operations. Botti approaches can further be subdivided according to structured ver- 
sus unstructured software touchpoint 

The Trap to CU Approach for structured Instruction Level Touct^'nts. Ftg, 22 shows a host system processor 
fetching instaicttons fiwi tfie memory code image 221 of an applicatfon which has structured instruction level touch- 
points 222 installed. In the trap to CU approach, tfie host system processor 223 raises an exc^>tion when encountering 
a touchpoint start instruction. The exceptfon handler invokes tfie CU component to remove the touchpoint and replace 
the touchpoint data witfi executable instructions. The host system processor then continues to execute the application. 
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Upoi detecting the touchpoint end instruction, the host system processor traps again and the CU can transform the 
memory image back to the touchpoint state. 

The h<^ system processor uses the tp.start instruction to raise an exception which cause the CU to be invoked. 
The CU is then given the knowledge of the memory address range and the memory kxatfon of the touchpoint to trans- 
form the touc^int body nito an instruction sequence which can be executed by ttw host system processor. Control 
then returns back to the host system processor. Once the touchpoint is translated in this feshion, other application 
instances could potentially access the touchpoint area. It is therefore important to Implement the touchpoints as a ait- 
ical section in which no application context switching Is aifowed. Upon end of the touchpoint in^ruction sequence, the 
tp^end if^truction causes a trap to the CU which altows the CU t^ 

Use of Host System Processor Elements for structured Instruction Ijevel Touchpoints. Rg. 23 is a bk)ck sdiematic 
dia^am that illustrate insfruction level toudpoint si^aport ir^e the host system fKiocessor. TWs seccrKl approach 
assiOTies that the host sy^em processor 223 has a built in togk; conponent 230 whidi aflows it to the decode the toiK^- 
point during instruction fetch. Upiwi encountering a to^ instructm the host systerh^ f^^ 

the toudpoint data wthin the processor's cache 224 and continues the execution. t4o memory image changes take 
place. Upon encountering the touchpoint end instruction, the cache line 225 is flushed or left for future use. To suf^rt 
tWs scheme, toucfpoints are reqdred to align on a cache boundary which shcHJfcl be a multipfe of the cache line size. 

Upon detecting a tp^start instruction by the host system processor instruction fetch unit, the host system first 
fetcT^s and th^ fransforms one or more cache lines that contain the toudpoait area, usir^ the key stored in a host 
systm proce^ control register 226. Each appScatkm m^ have a different tp^reg value for resolving the totK^f^nt 
area. Tlietp_reg value is part of the COS-TP whkrfi was used to instafl the applteation in the host system. The loadir^ 
of the tp^reg control register at context switch involves the CU as the keeper of the Hiformafion , The tey^reg value could 
also be made part of the appTication context state, so thm it can t>e foaded du^ 
CU. 

Af^sroaches for unstructured Instruction t.evel T<HJCfpoints and Data Level Taicfpoints. Both unstructured instruc- 
tion level toucf^xrfnts and data level toucfpoints are charact^ ized by the absence of any meta infdrmalioo about the 
toud^Mints at the touchpc^ kx:atoi itself . The appro^ 

two steps. The first step conc^Tis the detection of these touchpoints, the second step resolves them before the host 
system processor accesses that area. 

To detect a toucfpant area, medianrsms must be put into place in both the software environment and the hardware 
to propagate the informatfon about the focatfon of the touchpoints to tfie host system proce^ng elements. For exam- 
pte. if tfie ^ularfty of the toucf^xM areas ts chosen to foe on a page size of the 

system, the Informatrcm about the toudpoimfocationooufcibeccmnunicatedtfvoughfhepage tables and translation 
took aside buffers to the host system processor. 

During address transfatfon, the host processor can detect whether the address range to be transtef ed contains soft- 
ware toucf^xwtts or not When loading the cache line for executi cm or access from a touchpoint page by the host system 
proc^sor. ^e toudpoint area is resolved in the cache stteystem as described abova SMar techniques apply when 
the rescued touchpoint areas are kept in the cache lines and are not accesstl)^^ 

tfie oi^ects that contain tfiem. Read only cache lines are simply flushed wherever they are not needed anymore Cache 
lin« modified rrujst be transformed back before they are wrfften back to the main memory syrtem. 

Although the inversion is d^cribed herein with reference to the fxeferred embodiment, one skilled in tfie art will 
readily appr^aate that other applications may be substituted for those set forth herein witfiout d^3arting from the spirit 
and scope of the present inventfon. Accordingly, the invwitfon shouM only be limited by the Claims induded below. 

Claims 

1 . An apparatos for validating that an application (29) r^htfully executes a certain dass of sendee (26), conprising: 

an application domain authority (22) for granting a level of authority in the fbrm of a cert9k:ate (28) containing 
valid dasses of servfoe; and 

means (14) for t^htly binding sakJ appficaton to said certificate. 

2. The apparatus of Claim 1 . Hirther comprteing: 

a cryptographic unit (14); and 

means (12) for establishing trust between said applicatfon and said ayptographic mit wherein said application 
is assured that said cryptographic unit has not been tampered with. 

3. The apparatus of either of Claims 1 and 2. further comprising: 
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a trusted load subsystem (12) for performing application validation; 

means (14) fa loading a program image into a system memory space: and while doing that, valfdatino that said 
application has not been tampered with. 

4. The apparati^ of Claim 3. wherein said trusted load subsystem further comprises: 

means (27) for using a checksum over a pfxjgram image; 

wherein the toad fails and said program image is not loaded if the checksum does not match a check- 
sum stored by a loader subsystem at application tnstallatkxi time. 

5, TheapparatusofanyofClaims1to4.ftirtherconprlsing: 
'"e^ns (27) for vaSdating any object governed by 

IS 6. Tlieapparafusofanyof (bairns 1 to 5. further comprising: 
means (27) for chaflenging said cryptographic unit 

7. Theapparatusofanyofaaims1to6,whereinsaidapplicationi^ 

said apparatus further conprising: 

means (30) for preparing said appficatfon to function with said cryptographic unit; 
» only a cryptographic unit which has a con-ect decryption key can unscramble saki applk»tfon, 

8. T?ie apparatus of any of Ctaimsl to 7, further conprising: 

means (26) for creating ctesses of service with a security domain authority (20) from pdictes defined to meet 
30 ff™^i^ authwities' security intirests and requirements, where saki dass of sendee has a unfoue 

KfenTication that is not reused by said security domain authority, 

9. TTiea^^ratusofanyofCtemisI to8.furtherconprising: 

35 means (22) for defining classes of servfoe with saki applfcation domain authority, where sakJ classes of sendee 

are validated by a security domain authority that has polkaes defined to meet saki security domain authorities^ 
security interests and requirements, where saki dass of service has a umque kfenfiffcatfon that fe not reused 
t^ saki security domain authority. 

^ 10. The apparatus of any of Claims 1 to ft further conprising: 

means (26) for provkling a dass of service from saki security domain authority (20) to saki appricatfon domain 
authority (22) to allow said application domain authority to issue applk»tion certTicates (28) for an applk:atfon 
whfch contains sakJ dass of servfoe; 
^ wherein a path of access oontfof is formed. 

11, The apparatus of any of Qaims 1 to 10. wherein an application must have a certif kate to access a method kienti. 
f led by saci dass of senoca 

so 12. The apparatus of any of Claknsi to 11. further comprising: 

means (28) for propagating a dass of service to sakj cryptographic unit to enable saki dass of servfce at a tar- 
get ayptogiaphk; unit; 

wherein methods labeled by saki class of service must be in a present state for a request to be exe- 

ss cuted. 

13. TTie apparatus of any of Claims Ito 1 2. wheran both control of access and control of existence of a method must 
always be present to maintain a method defined by said appfication m a functioning state. 
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14. in appamtusofanyofOaimsl to 13. further cofi^ 

a policy (12) for activating said cryptographic imti before an application can be granted a dass of service via 
said ap^tcation certTicate. 

15. of aaims 1 to 14, wherein said cryptographic unit (14) must be in communication with a pol- 
fcy (12) for said classed service to be downloaded. 

16. The appaiatus of any of Oaims 1 to 15. further oonprising: 

a virtue poGcy (1 2) that requires a networii connection to a network security server (1 8) to distribute said virtual 
policy to sakf cryptdg^^^ 

17. The apparatus of any of ClaiiTTsI to 15. further coriprising: 

a physical policy (12) that requires said cryptographic unit (14) to implement touchpoints in hardware: 
wherein said towjhpoints are placed in detern^rastic locations in sakJ hardware: and 
wh^ein a polk^ contaiiting touchpoint data can be loaded, but cannot be removed from said crypto- 

5Wh*c wit without a decay of said appTication's ftjnction. 

la-meappamtusofanyofCW 

touchpomts inside said cryptographic unit 

19. The apparatus of any of Qaims 1 to 18. wher&n said class of service contains a method field (51) that describes 
an actual method for which said dass of service stands. 

20. TlTeapparatusofanyofCiai 
attributes of said method. 

21. "n^eapparatu5ofanyofaams1to20.whereintheirtervaJfor 

may be an unbounded or may be oonstmined t^ predetemiined aiterta. 

22. Theappara!usofanyofaaims1to21.saiddassofservfcefurthera^ 

a spedal. predef tfied dass of service that is used to guaid dass of service decay functionality. 

23. The apparatus^ of any of Claims 1 to 22. wherein dasses off service are organized not only by an object that they 
descnbe.^dsobya level of valkiatfon or setoff constraints art impfemeii^ peilbrms before granting a service 
level descnbed by said dass of servica 

24. -me apparatus of any of Claims 1 to 23. wherein tighter validation and contrd over a service to be granted is 
achieved based upon said level of validation or set of constraints. 

25. The apparatus of any of Claims 1 to 24. further coriprising: 

a dass of service level that vafidates a dass of service 1 0. as it is made available through an application certif- 
icate, has been signed by a security domain authority. 

26. TheapparatusofanyofOaimsl to 25. further con^sing: 

a dass of service level that requires validation of said applicalfon c^icate. where said certificate is required 
to be issued by said application domain authority that r^^ 
sennce to from said security domain authority 

27. The apparatus of any of Claims 1 to 26. further comprising: 

a dass of service level that requires validation of said application ID issued by said application domain author- 
ity. 
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28. The apparatus of any of Claims 1 to 27. further conprising: 

a dass of service level that requires interaction wfth a national security server to validate said dass of service 
requested tsy said application. 

29- The apparatus of any of Claims 1 to 28, further oonprising: 

a dass of service level that interacts with said national security server on each operation requested by said 
appfication. 

30- The apparatus of any of Claims 1 to 29. further convrising: 

^ dass of service level that requires a token (50) for any orte. orcbntfifnatidri of. validations arxl iriteractibns. 

31 . The apparatus of ary of Claims 1 to 30. wherein said dass of service levels may be provided alone or in con^ina- 
tion. 
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